1. Field of the Invention
The present invention relates to a session initiation protocol (SIP) application service, and more particularly to a method and system for providing redundant load balancers for the SIP application service; a mechanism for distributing SIP requests/dialogues to SIP proxies and servers based on optimization factors including load, availability, cost and proximity of one or both dialogue endpoints; and a mechanism for redirecting SIP requests/dialogues to a peer load balancer when it is determined that a server under the peer's control is most optimally suited to handle the dialogue. As SIP load balancers inherently act as SIP proxies, the mechanism for redundant load balancers can be applied to other types of SIP proxies (i.e. to provide globally redundant SIP proxies).
2. Description of Related Art
The rapid evolution of voice and data technology is significantly changing the business environment. The introduction of services such as instant messaging, integrated voice and email, and follow me services has contributed to a work environment where employees can communicate much more efficiently, thus increasing productivity. To meet the demands of the changing business environment businesses are deploying converged voice-and-data networks based on a SIP application service.
As businesses continue to increase their use and reliance on converged services, reliability and availability becomes increasingly important. High availability and optimized solutions for IP networks address the need for users to be able to place and receive calls under peak-load call rates or during device maintenance or failure. In addition to lost productivity, network downtime often results in lost revenue, customer dissatisfaction, and even a weakened market position. Various situations can take devices off line, ranging from planned downtime for maintenance to catastrophic failure.
Today, high availability and optimized solutions for a SIP application service is usually achieved by distributing the service across multiple servers and using a load balancer to distribute SIP requests amongst the servers. The load balancer insures that requests pertaining to the same session/dialogue are persistently distributed to the same server (if this is a requirement and it usually is). In order to insure true SIP load balancing, it is usually required that the load balancer act as a SIP proxy (usually stateless), which is typically a call-control device that provides many services such as routing of SIP messages between SIP user agents. This is particularly true when load balancing SIP over TCP/TLS, since TCP splitting and/or multiplexing are usually required. In addition, the load balancer monitors the health, load, and availability of each of the servers. When a server fails or its availability is least optimal (relative to other servers), the load balancer stops distributing requests to that server.
For redundancy a second load balancing device is usually deployed on the same network and serves as a backup to the active load balancer, often incorporating Virtual Router Redundancy Protocol (VRRP) and a synchronizing mechanism. The load balancers themselves (active and backup) are always deployed on the same geographical site. The servers may be deployed on the same geographical site, or alternatively, on some deployments the load balancer (and its backup) and the servers may deployed on separate geographic sites. The servers themselves may also be deployed on several separate sites. Thus, if a site containing a group of servers fails, other servers deployed on the other sites remain available. However, the fact that both load balancers are deployed on the same geographic site leaves the system susceptible to complete site failure (e.g. natural disaster, geographic power shortage, etc.).
In addition to geographic distribution of the servers, the prior art proposes another solution involving deploying load balancers on two or more sites. Each load balancer is assigned a unique VIP (Virtual IP addresses) through which the SIP application service is invoked. Each SIP client is aware of each of the VIPs, with one configured as the active VIP to which it directs SIP requests. The other VIPs are configured as backups.
In addition, each SIP client monitors the active VIP (i.e. the active load balancer), and if it detects that the active load balancer fails, it directs its SIP requests to the backup. If SIP over TCP is used, for example, a load balancer can be detected as failed when one or more TCP connections to that VIP fail. When the formerly active load balancer returns (again detected by the client), SIP requests can again be directed to the active VIP.
However, this solution is most limited as it requires each SIP client to monitor the load balancers and to be configured with backup VIPs for each service. Furthermore, the client must be aware that when the active load balancer returns, requests pertaining to existing sessions must continue to be directed to the backup. Most often, the client is either unknown in advance or is non-configurable to this behavior making this solution highly unfeasible.
Another problem with the prior art is, even when some of the servers are deployed on separate geographical sites, the distribution algorithms of the load balancers do not take the site locations into consideration, ignoring the fact that proximity of the servers to one or both of the call endpoints can contribute to the effective availability of the SIP service, including latency and QOS. This is of particular importance for voice applications, which comprise a large part of all SIP based applications.
Geographic load balancing mechanisms used for HTTP and other web applications cannot be applied to SIP applications without major limitations. Although SIP is an HTTP like request-response protocol, there are certain fundamental differences that make the problem unique. This is due largely to the peer to peer and asynchronous nature of the SIP protocol, the fact that SIP requests traverse multiple application level nodes limiting redirection capabilities mid path, the higher QOS requirements of voice applications and SIP servers can use TCP, UDP and SCTP transports.
Thus in typically prior art solutions, if a site containing a group of servers fails, other servers deployed on the other sites remain available, however, this does not address failure of the site on which the load balancers (active and local backup) are deployed. Furthermore the prior art does not optimize the load balance distribution algorithm by taking into account SIP server proximity to one or both of the session/dialogue endpoints. It would be advantageous to geographical distribute SIP load balancers and account for SIP server proximity to one or both of the session/dialogue endpoints.
Whatever the precise merits, features, and advantages of the prior art is, none of them achieves or fulfills the purposes or advantages of the present invention.